Persisted queries
下記から要点をまとめる。
とは？
サーバもクライアントも互いにやりとりするクエリが事前に分かっているのなら、いちいちその間でクエリ全文をやり取りする必要はないはず
いちいちクエリ全文をやりとりすると、その分帯域が占められてしまう
クエリと一意な ID をマッピングし、一意な ID と必要な変数値のみやりとり することで、クライアント/GraphQL サーバ間の通信量を減らすことができる
サポートツール
Apollo 製のものだと以下のようなものがある。
table:ツール群
ツール名 概要
Automatic persisted queries Apollo Link 及び Engine のビルドインの機能
persistgraphql GraphQL をビルド時に静的解析するライブラリ
persistgraphql
GraphQL サーバを建てたときにやりたいこと
サーバ側が受付可能なクエリをホワイトリスト形式で制限したい
完全な GraphQL クエリを送信する代わりに、クエリのIDもしくはハッシュを送ることでサーバ/クライアント間の帯域を節約したい
Persisted Query は上記をサポートしてくれる。
persisted query とは？
graphql-tag/loader webpack loader で .graphql ファイルをインポートできるようにしている
Comment.graphql に記述されたクエリを実行する
クライアントは完全なクエリを文字列としてサーバに送る
サーバはクエリを確認し解決しデータを返す
上記が全てランタイムに生じるため、帯域が占有されるし際限なく実行される
ビルド時にクライアントがどのようなクエリを送ってくるかわかるようにしたい
そもそも、問い合わせる内容自体は事前に Comment.graphql 内にある
クエリをサーバ側に登録しておき、クエリは何らかの ID やハッシュのみサーバに渡す
利点
クエリを全て送らないので帯域を節約できる
既に知っているクエリのみ解決し、攻撃者からのクエリを防御できる
persisted query
番号とクエリのマッピングの合意のこと
具体的には GraphQL ドキュメントと生成された ID のマッピング
これを実装するためには、クエリが静的解析可能である必要がある
つまり、ビルド時に クライアントが送信したいクエリが何なのかわかる必要がある
https://cdn-images-1.medium.com/max/2000/1*oJGTuYheBaaiirGsKIosrQ.png
persistgraphql
ソースコードリポジトリ内に配置され、GraphQL ドキュメントを出力し、それと生成された ID 間のマッピングを JSON ファイルに書き出す
ネットワークインタフェース実装もある。全てのクエリを扱えるが、クエリ ID のみをサーバに送信するインタフェース